Remarks 

Applicant respectfully requests reconsideration of this application. Claims 1-27 
are currently pending. 

Claims 1,2,5,11,18,19, and 22 have been amended. No claims have been 
cancelled. No claims have been added. 

Therefore, claims 1-27 are now presented for examination. 

Claim Rejections under 35 U.S.C §112 

The Examiner has objected to Claim 5, 7, 10, 1 1, 14, 22, and 25 as being 
indefinite for failing to particularly point out and distinctly claim the subject matter. 

Claims 5,11, and 22 have been amended to remove the phrase 'that may be 
guarded". The remaining rejected claims were rejected as being dependent on these 
claims. 

It is submitted that removal of this phrase fully addresses the rejection as the 
description of the program objects is each such claim is now clear in meaning. 

Claim Rejections under 35 U.S.C. §102 
Bacon, et al. 

The Examiner rejected claims 1, 3, 4, 18, 20, and 21 under 35 U.S.C. 102(e) as 
being anticipated by U.S. Patent Publication No. 2005/0149588 of Bacon et al., 
("Bacon"). 

Claim 1, as amended here, provides as follows: 

1 . A method comprising: 

receiving an access request for a program object; 
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performing a combined check for a null reference and for a read 
barrier for the program object, the combined check 
including performing a speculative load in response to the 
read request and performing a speculation check for the 
speculative load; and 

if the speculative load is unsuccessfid, performing a recovery 
operation including: 

determining if a read barrier is needed, and 
if a read barrier is needed, performing a read barrier 
process. 

In addition to any other differences, it is respectively submitted that the cited 
references do not provide for a combined check for a null reference and for a read barrier 
for the program object including performing a speculative load in response to the read 
request and performing a speculation check for the speculative load. 

Bacon regards a system for optimizing away a null check. Specifically the 
reference regards a garbage collection system that needs to meet real-time requirements 
combining a null check required for an application with a null check required by its read 
barrier. (Bacon, Tf 0007) In this context: "Read barrier is a term of art that describes a 
special check performed each time application code fetches a value from a heap memory 
location. The read barrier serves to coordinate the application processing with the 
garbage collection. The read barrier checks each pointer reference to verify that the object 
accessed through the pointer is not being moved." (Bacon, 0006) 

As claim 1 has been amended, the method includes performing a combined check 

for a null reference and for a read barrier for the program object, the combined check 

including performing a speculative load in response to the read request and performing a 

speculation check for the speculative load. As indicated in the Office Action, Bacon does 
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not provide for performing a speculative load in response to a request. For at least this 
reason, Bacon does not anticipate the rejected claims. 

Claim Rejection under 35 U.S.C. §103 
Bacon et aL in view of Arimilli et al. 

The Examiner rejected claims 2, 15-17, 19 and 22-28 under 35 U.S.C. 103(a) as 
being unpatentable over Bacon in view of U.S Patent No. 6,880,073 of Arimilli et al. 
CArimiliry 

Arimilli regards speculative execution of instructions and processes before 
completion of preceding barrier operations. The reference provides: 

Described is a data processing system and processor that provides 
full multiprocessor speculation by which all instructions subsequent to 
barrier operations in a instruction sequence are speculatively executed 
while the barrier operation is executing on the system bus (i.e., before the 
barrier operation completes and an acknowledgment is received at the 
issuing processor). 

(Arimilli, col. 2, lines 59-65) Thus, what the reference regards speculative execution of 
all instructions "subsequent to barrier operations in an instruction sequence" are 
speculatively loaded while the barrier operation is executing on the system bus. 

It is submitted that the Arimilli is not relevant to the claims for at least the 
following reasons: 

(1) The term "barrier operation" is completely unrelated to a "read barrier". The 
common word "barrier" is simply coincidental. What the reference is discussing is the 
execution of "barrier instructions" that separate groups of instructions. This is explained 
as follows: 
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Barrier instructions are placed within the instruction sequence to 
separate groups of instructions and ensure that all instructions within a 
first group are fully executed (i.e., the corresponding operations and 
results are visible to all other processors) before any instruction within a 
subsequent group is executed. The instruction set architecture (ISA) 
supported by most commercially available processors includes a barrier 
instruction, which initiates a barrier operation on the system . In the 
PowerPC™, family of processors, for example, one barrier instruction that 
is employed to establish a processing boundary is the "sync" instruction, 
and the corresponding transaction on the system bus is called a 
synchronization operation (sync op). Other barrier instructions exist within 
the instruction set, but synch ops will be utilized generally within the 
present document to refer to global barrier instructions. 

(Arimilli, col. 2, lines 7-22) Thus, in the terminology used in the Arimilli reference, a 
"barrier instruction" is intended to separate groups of instructions, and initiates a "barrier 
operation" on the system. An example of a barrier instruction is the described "sync" 
instruction, initiating the synchronization barrier operation. This has no connection with 
a read barrier, which, as indicated in the specification of the current application, operates * 
to trap access to a guarded program object, with the system guarding all read accesses to 
an object with a check to determine whether an access touches a guarded object. 

Thus, the Arimilli contains no teach or suggestion of any operation relating to a 
read barrier. 

(2) Even if it were assumed that Arimilli were related to a read barrier, the 
description of speculative operations is irrelevant to the operations described in claim 1 . 
As indicated above, the process provides for speculative execution of all instructions 
subsequent to barrier operations in an instruction sequence. This makes no sense in 
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connection with claim 1, in which a speculative load is utilized as part of the read barrier. 
Speculative execution of an instruction subsequent to barrier operations would not 
institute a read barrier - for claim 1 the speculative load is instituted to perform the read 
barrier. Further, speculative execution of all instructions subsequent to barrier 
operations , as provided in Arimilli, does not make any sense for the read barrier, as it is 
only the access request to an object that triggers a read barrier. 

Thus, even if it is assumed for the sake of argument that the references are 
combinable, the combination of Bacon and Arimilli would not produce the elements of 
claim 1 . Neither of the references includes the elements of claim 1 . 

It is submitted that the arguments provided above with regard to claim 1 are also 
applicable to independent claims 5, 1 1, and 18, and such claims are thus also allowable. 
The remaining claims are dependent claims, and are allowable as being dependent on the 
allowable base claims. 

Conclusion 

Applicant respectfully submits that the rejections have been overcome by the 
amendment and remark, and that the claims as amended are now in condition for 
allowance. Accordingly, Applicant respectfully requests the rejections be withdrawn and 
the claims as amended be allowed. 
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Invitation for a Telephone Interview 

The Examiner is requested to call the undersigned at (503) 439-8778 if there 
remains any issue with allowance of the case. 

Request for an Extension of Time if Needed 

The Applicant respectfully petitions for an extension of time to respond to the 
outstanding Office Action pursuant to 37 C.F.R. § 1.136(a) should one be needed. Please 
charge any fee to our Deposit Account No. 02-2666. 



Charge our Deposit Account 



Please charge any shortage to our Deposit Account No. 02-2666. 



Respectfully submitted, 



BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN LLP 



Date: April 10, 2008 



/Mark C Van Ness/ 



Mark C. Van Ness 
Reg. No. 39,865 



1279 Oakmead Parkway 
Sunnyvale, CA 94085-4040 
(503) 439-8778 
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